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This Declaration is submitted by the undersigned Michael A. Glenn who makes 
the following declaration based on information and belief of the facts involved: 

1 . The Declarant is a citizen of the United States of America. He resides at 3475 
Edison Way, Suite L, Menlo Park, California 94025. His mailing address is 
3475 Edison Way, Suite L, Menlo Park, California 94025. 
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Attorney ] 
2. 



Docket No. QUAC0002 Application Serial No. 09/532,509 

. The Declarant is a registered Patent Attorney, Reg. No. 30, 1 76. 



3. The Declarant represents the Applicant in the above-indicated Patent 
Application Serial No. 09/532,509. 

4. Claims 9-22 are rejected under 35 U.S.C. § 102(e) in view of United States 
Patent No. 6,510,417 to Partovi et al. (hereinafter referred to as "Partovi"). 
Partovi was filed on October 22, 1999 and therefore is prior art under 35 
U.S.C. § 102(e) as of October 22, 1999. Partovi does not claim the same 
invention as those set forth in Claims 9-22. To avoid Partovi as prior art 
under 35 U.S.C. § 102(e), the Applicants must show "conception of the 
invention prior to the effective date of [Partovi] coupled with due diligence 
from prior to said date to a subsequent reduction to practice or to the filing of 
the application," see 37 C.F.R. § 1.131(b). 

5. The Declarant and the Applicant made an exhaustive search of the Applicant's 
records to obtain evidence relating to the date of conception of the invention 
and relating to the Applicant's diligence in reducing the invention to practice 

6. The search produced documentary evidence demonstrating the conception of 
the claimed invention as early as September 17, 1999. The documentation is 
attached herein as Exhibit A and is entitled "Quackware Voice Portal 
Functional Requirements". 
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7. Exhibit A bears a date of September 17, 1999. The portions of the document 
which are free of any markings were prepared as of September 17, 1999. 

8. Exhibit A also bears a second date of March 26, 2001. The second date is 
marked with a vertical line in right margin of the document and marked with 
an underline. This marking is consistent with markings used by document 
editing software tools, such as Microsoft Word's "Track Changes" feature. 
Such editing tools indicate revisions made to a document with underlining and 
include a vertical bar in the right margin next to portions of the document that 
have been changed from the original version. Likewise, the portions of the 
documents which lack these markings are the original portions of the 
document. 

9. For the purpose of this Declaration, the Declarant refers only to those portions 
of Exhibit "A" that are part of the original document which do not include 
vertical bars or underlined information. Accordingly, the Declarant refers 
only to original information memorialized on or before September 17, 1999. 

10. The pending Claims, in their current form, are clearly enabled by the original 
portions of Exhibit A. A claims chart is attached herein as Exhibit "B" to 
show the pending claims mapped to the disclosure of Exhibit "A". 
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1 1 . Accordingly, Exhibit "A" provides evidence showing that the Applicant 
conceived of the claimed invention prior to October 22, 1999. 

12. Between September 17, 1999 and March 21, 2000, the Applicants were 
actively engaged in diligently reducing to practice the invention as broadly 
disclosed and claimed in the above-identified patent application. The 
Applicants' diligence is memorialized in the originally filed specification, 
drawings, and claims, filed on March 21, 2000. 

13. These statements are made with knowledge that willful false statements are 
punishable by fine and/or imprisonment under 18 USC 1001, and that any 
such willful false statement may jeopardize the validity of this application or 
any patent resulting therefrom. 




Date: 



Michael A. Glenn 



Reg. No. 30,176 
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Quackware Voice 
Portal Functional 
Requirements 



March 26. 2001 ' September 18. 1999 

CTO/CSA Edits Only 
CMO Comments 9-17-99 




This document captures the functional requirements for the 
Quackware Voice Portal (QVP) system. 
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This document specifies the functional requirements for the Quackware Voice Portal (QVP) 
system. The requirements are organized by functional area. 

While most requirements listed in this document are intentionally generic (i.e. meant to be ap- 
plicable to a range of possible vertical applications), those which are specific to a particular 
vertical application are specified as such. This document is the Software Requirements 
Document specified in the Quackware Documentation Overview and Guide and is owned jointly 
by the CTO and the Chief Software Architect. All edits necessarily go through those individuals. 
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1 User Interface Requirements 

<describe overall model of finding items (Existants — anything that we provide access to) and 
getting information about items> 

1.1 Configuration and User Access 

<describe philosophy that users may or may not be subscribed to QVP in advance> 

1 . The user may use the Quackware Voice Portal without pre-subscription. 

2. The user may specify profile information, including addresses and credit card numbers, 
upon subscription. What your assumptions here- via QVR, web, human operator? 

3. The user will specify a personal numeric password for transactions requiring authentication 
(e.g. purchasing or bidding). 

4. The user will be identified by a phone number, either spoken or determined via caller ID. 

5. The user may modify personal information, such as addresses and credit card numbers. 
^ame^s^m^o^s^as^!. QW will verify credit card information in real time, (exact name, 
billing st. address, zip, CC#. exp date) to ensure accounts are set up accurately. 

6. The system will provide the user will shortcuts to commonly used functions. 



1.2 Item Selection 

<describe philosophy on funneling and data presentation> 



1 . The user may specify the domain of interest (e.g. e-commerce, traffic information, weather 
information, movies, etc.). 

2. The user may choose an item (e.g. a book, a toy, a route of interest for traffic information, a 
city of interest for weather information, etc.) by specifying (possibly partially) attributes of 
the item. 1 

3. The user will be provided with detailed information for an identified item, appropriate to the 
domain of the item (e.g. products, traffic, weather, movies, etc.). Specifically: 

• E-commerce: reviews, vendor information including pricing, shipping costs and 
availability. 

• Movies: directory, producer, cast, etc. 



Auctions:outstanding bids. 
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4. The user may request information by locale (e.g. the nearest vendor for an identified 
product, the nearest theater for a movie). Ideally with multiple ways they can identify a 
locale (zip, town name, city area "Boston North, West etc.) 

5. The user will be provided with the , date and time on which information was last updated._(]f 
reqested) 

6. All data presented to the user will be of currency appropriate to the domain. 

7. The user will be provided with information for any item offered by a supported data source. 
This is unclear to me - please explain 

8. The user will be informed of the source of the information ("provided by XXXXX") 

9. A "help" or "instructions" option will be available at every selection point 

10. The user can request a listing of all possible choices at any selection point. 

1.3 Item Comparison 

<describe philosophy on relatedness and comparison> 

1 . The user may request item comparisons based on item attributes, as appropriate to the 
domain. 

2. The user may request identification of better , cheaper and related items, as appropriate 
to the domain. 

1.4 Transactions 

<different transactions (bid/watch/buy/track) are appropriate to different domains; section is di- 
vided by domain> 

1.4.1 E-Commerce Domain 

1 . The user may order an identified product from a chosen vendor. 

2. The user may add an item to a shopping cart for purchase at a later time- 
rs. T he user may specify, when ordering, a billing credit card and shipping address (from 

user profile or manually). Is "manally" via,human operator? 

3t 4. The user may request status information for previously ordered products. 

1.4.2 Auction Domain 

1. The user may increase existing bids. 

2. The. user may place bids on new auctions. 
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1.5 User Input (IVR only) 

1 . The system shall use word-based automatic speech recognition (ASR) for accepting user 
input wherever possible. . 

2. The system shall use spelling-based ASR for accepting user input when word-based ASR is 
not possible. 

3. The system shall use keypad entry for accepting user input only when no other option is 
feasible. 



1.6 Item Lists, Monitoring and Notification 

^%the user may explicitly record items in named lists, as appropriate to the domain', f don't 

2. The user may review items from their lists. 

3. The user may request phone or email notification of information changes (appropriate to the 
domain) for items on their lists. 
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2 Virtual Database Requirements 

Quackware s virtual database technology is designed to deliver information garnered from the 
web to our customers in a timely and highly utilitarian way.. Quackware s philosophy is that 
people need and use information in a variety of settings and ways, and we wish to support this 
on a variety of platforms including but not limited to the phone (voice, WAP and both), the web, 
and portable connected computing devices (PVII, WinCE, etc). 

This section provides an outline of features that will be implemented in Quackware s backend 
database service support. 

2.1 Data Collection 

1 . The system shall collect data from supported sources at regular intervals to be scheduled 
for particular item types and/or sites. 

2. The system shall detect changes to data source sites and notify the appropriate site rule 
maintainer. 

3. The system shall support non-expert definition of data extraction for data sources. 

4. The system shall support evolutionary development of data extraction for data sources. 

2.2 Fusion 

1 . The system shall correctly identify identical items from different vendors. 

2. The system shall retain meta data about the source of all information. 

3 v3. T he system shall support interactive clarification of fusion decisions or non-decisions in 
cases where certainty can not be determined automatically. 

T he system shall support additions of new data types and data elements, without code 
change, provided they are not part of a limited top-level set in Quackware s -hierarchy. 

4 v5. T he system shall support domain-specific concepts of relatedness that will to a large 
extent be identified through market research/trial/opportunity. 

_ E-commerce: cheaper, better, often-bought-with, most-popular, etc 

_ Movies: related movies and products, best movies in a category, most popular, best by 
reviewer, etc. 

6. The system shall collect and retain related information neccesary to provide additional detail 
about an item (e.g product descriptions) 



Confidential 



Page 7 



3/26/01 09/18/99 



3 Advertising Requirements 



<describe advertising philosophy; utility = ^availability, relatedness to current item (e.g. DVD w/ 
TV), relevance to user (e.g. by demographic), desirability to advertiser, value to Quackware 
(e.g. based on cost/return))> 

1 The system shall provide an initial general advertisement or sponsorship message to all 

callers 

4/The system shall provide targeted audio advertisements to users, chosen based on a utility 
function appropriate to the domain. (IVR interface) 

The system shall have the capability to provide a secondary message with more detail upon 
reguest (verbal click-through). 

2. The system shall provide targeted banner advertisements to users, chosen based on a 
utility function appropriate to the domain. (WWW interface) 

^T^f^f^lhall provide selectable permission-based advertisements to users HMH 



4. The system shall keep a record of all advertisements served to users, including successful 
(complete) and unsuccessful (incomplete) deliveries. This feature will need to be auditable 
and, may be composed entirely or partially from off-the-shelf components or facilitated 
through a click-auditing partner. 




Advertisements shall be targeted by domain, or caller location. 
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4 Customer Management 

In order to continually add value and transition with customers from one platform to another (for 
example from the phone to the web, or from the phone to WAP), it is in our interests to support 
personalization features to improve customers experience with our services. In addition to per- 
sonalization, other sources of stickiness (customers sticking with Quackware in light of in- 
evitable competition) include the support of community features such as networks of friends or 
of folks with common interests. 

In order to support any adaptation of service (or advertising) to customer behaviour, it is to our 
advantage to track customer use of Quackware services. This should be seen as a basic re- 
quirement of all services. In support of this, coordination needs to be created between front- 
end interaction support (for example, in the Quackware Speech Layer). Services and a logging 
mechanism. Early versions of this can be necessarily simple as long as we identify an appro- 
priate way of tracking use early. 

Further in the area of interface evaluation, typical customer explorations of our interface hierar- 
chies can help us identify problem areas (options never exercised for example), or very useful 
areas* or correlated sets of sub-features in single sessions. A example of an important attribute 
to include would be timing — for example, in the QSL the use of barge-in can signify a more al- 
vanced user and a string of barge-in selections to a single sub-tree repeatedly for a specific 
customer can be a great opportunity for a short-cut — either a general one, or possibly a cb- 
tomer-specific one. 

A critical aspect of stickiness is adaptation of services to a customer s preferences. While this 
can include relatively simple features such as customer information retention in support of non- 
repetitive sign-up or purchasing data-entry requirements, it can also include preferences for 
navigation of particular sub-trees of interaction in different front-ends, and preferences for serv- 
ice/vendor ordering or selection. As an example of vendor preference or ordering, one option 
for pricefone feature is preferred vendor — thus allowing us to limit a list of vendors for a found 
product to two : cheapest and preferred. There are other alternatives, but this shows a suc- 
cessful tradeoff of cheap browsing elimination and successful limitation of the problems of 
speech-based list navigation for long lists. 

The customer database and the advertising database are clearly highly related as careful 
tracking of advertisements to consumers and consumer requests for advertisements are the 
core of our business model (see also advertising database requirements). 

1. The system shall record all user transactions, for both subscribed and unsubscribed users. 

2. The system shall record items that the user locates in a history list. 

3. The system shall use passive means for customer identification whenever possible. 

4. The system will maintain customer preferences appropriate to each supported domain. 
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5. The system will update customer data from data sources dynamically. Specifically: 

• Auctions: current bid status updated on user request. 

6. The system will present user data with currency appropriate to the domain. Specifically: 

• Auctions: bids are always current to within seconds. 

• E-commerce: pricing information is current when purchase price is presented. 

7. The system shall derive customer behavior statistics by demographic. 

8. At no time shall individual customer information associated with a particular customer by 
any unique identifying characteristic be used without the customer s permission outside of 
Quackware, Inc. 

9. Customer information will be secured and carefully controlled from unauthorized access. 



EXHIBIT B 



Claim 9 


Evidence of Prior Conception 


A voice-controlled transaction service adapted 
to process transactions over the Internet, the 
service comprising 


Exhibit A, Page 6, Section 2, "Virtual Database 
Requirements" 


a user interface; and 


Exhibit A, Page 3, Section 1.1, "Configuration and User 
Access" 


at least one database coupled to the user 
interface, the user interface coordinating voice 
communications with a user, the voice 
communications including item or service 
information and transactions associated with the 
item or service, the at least one database storing 
item and service information; 


Exhibit A, Page 6, Section 2, "Virtual Database 
Requirements"; Section 2.1, "Data Collection"; Section 
2.2, "Fusion" 


whereby transactions are executed without the 
user pressing a button, clicking a mouse, or any 
other manual input to a computing device. 


Exhibit A, Page 6, Section 2, "Virtual Database 
Requirements" 






Claim 10 


Evidence of Prior Conception 


The service of claim 9, further comprising a 
network interface coupled to the at least one 
database, the network interface being 
configured to access the item and service 
information over the Internet, process requests 
related to the item and service information, and 
carry out transactions involving the identified 
item or service. 


Exhibit a, Page 6, Section 2, "Virtual Database 
Requirements" ("Quackware's vitrual technology is 
designed to ... support ... a variety of platforms 
including but not limited to the phone (voice, WAP and 

both, the web, and potable connected computing 
devices"; Exhibit A, Section 2.2, "Fusion" ("The system 
shall collect and retain related information necessary to 
provide additional detail about an item (e.g. product 
descriptions). 






Claim 11 


Evidence of Prior Conception 


The service of claim 10, further comprising a 

fusion engine configured to compare 
information obtained from at least one web site 
and selectively establish canonical data files 
corresponding to information gathered from 
multiple web sites. 


Exhibit A, Page 4, Section 1,3, "Item Comparison", 
Page 6, Section 2.2, "Fusion" 







Claim 12 


Evidence of Prior Conception 


The service of claim 9, further comprising a 
customer manager configured to record user 
information associated with user preferences 
and user behavior related to the service. 


Exhibit A, Page 6, Section 2.1, "Data Collection"; Page 
8, Section 4, "Customer Management" 






Claim 13 


Evidence of Prior Conception 


The service of claim 12, wherein the customer 

manager is configured to provide user 
information to the user interface such that the 
user interface may personalize the service for 
particular users. 


Exhibit A, Page 6, Section 2.1, "Data Collection"; Page 
8, Section 4, "Customer Management" 






Claim 14 


Evidence of Prior Conception 


The service of claim 9, further comprising an 
advertising subsystem configured to selectively 
provide the user interface with advertisements. 


Exhibit A, Page 7, Section 3, "Advertising 
Requirements" 







Claim 15 


Evidence of Prior Conception 


The service of claim 14, wherein the advertising 
subsystem provides the user interface with 
advertisements targeted to particular users 
based on information about the user. 


Exhibit A, Page 7, Section 3, "Advertising 
Requirements" 






Claim 16 


Evidence of Prior Conception 


The service of claim 9, further comprising an 
existant subsystem coupled to the at least one 

database, the existant subsystem being 
configured to manage- all information into and 
out of the at least one database. 


Exhibit A, Page 6, Section 2.1, "Data Collection"; Page 
8, Section 4, "Customer Management" 






Claim 17 


Evidence of Prior Conception 


A service for providing access to Internet-based 
information and execution of Internet-based 

transactions where the user communicates with 
the service using voice over a telephone, the 
service comprising: 


Exhibit A, Page 6, Section 2, "Virtual Database 
Requirements" 



means for providing information identifying an 
item or a service and providing a query as to a 
transaction to be performed which is related to 
the identified item or service; and 


Exhibit A, Pages 3-4, Section 1.2, "Item Selection", 
Section 1.4.1, "E-Commerce Domain" 


means for sending to a server system a request 

to execute the transaction related to the 
identified item or service in response to a user 
answer to the provided question. 


Exhibit A, Pages 3-4, Section 1.2, "Item Selection", 
Section 1.4.1, "E-Commerce Domain" 






Claim 18 


Evidence of Prior Conception 


The service of claim 17, further comprising 
means for retrieving information identifying an 
item or a service from a database. 


Exhibit A, Page 6, Section 2.1, "Data Collection" 






Claim 19 


Evidence of Prior Conception 


The service of claim 1 8, wherein the means for 
retrieving information identifying an item or a 
service from a database comprises means for 
retrieving information from the Internet. 


Exhibit a, Page 6, Section 2, "Virtual Database 
Requirements" ("Quackware's vitrual technology is 
designed to ... support ... a variety of platforms 
including but not limited to the phone (voice, WAP and 

both, the web, and potable connected computing 
devices"; Exhibit A, Section 2.2, "Fusion" ("The system 
shall collect and retain related information necessary to 
provide additional detail about an item (e.g. product 
descriptions). 







Claim 20 


Evidence of Prior Conception 


A computer program product comprising 
computer readable program code for execution 
a transaction related to an item or a service 
using a communication device, the program 
code in the computer program product 
comprising: 


Exhibit A, Page 6, Section 2, "Virtual Database 
Requirements" 


first computer readable program code for 
providing information identifying the item or 
the service; 


Exhibit A, Page 6, Section 2, "Virtual Database 
Requirements"; Section 2.1, "Data Collection"; Section 
2.2, "Fusion" 


second computer readable program code for 
providing a query as to a transaction to be 
performed related to the identified item or 
service; and 


Exhibit A, Page 6, Section 2.1, "Data Collection" 


third computer readable program code for 
sending to a server system a request to execute 
the transaction related to the identified item or 
service in response to the user response to the 

query, whereby the transaction is executed 
without the user performing a manual action. 


Exhibit A, Pages 3-4, Section 1 .2, "Item Selection", 
Section 1.4.1, "E-Commerce Domain" 







Claim 21 


Evidence of Prior Conception 


The computer program product of claim 20, 
further comprising fourth computer program 
code for gathering information from the 
Internet. 


Exhibit a, Page 6, Section 2, "Virtual Database 
Requirements" ("Quackware's vitrual technology is 
designed to ... support ... a variety of platforms 
including but not limited to the phone (voice, WAP and 

both, the web, and potable connected computing 
devices"; Exhibit A, Section 2.2, "Fusion" ("The system 
shall collect and retain related information necessary to 
provide additional detail about an item (e.g. product 
descriptions). 






Claim 22 


Evidence of Prior Conception 


The computer program product of claim 20, 
further comprising a fifth computer program 
code for performing comparisons between a 
plurality of transactions in order to chose an 
optimal transaction. 


Exhibit A, Page 4, Section 1,3, "Item Comparison", 
Page 6, Section 2.2, "Fusion" 



